Companies and other organizations typically maintain information about many different aspects of the organization in order to ensure efficient operation. This organizational information may include information that describes various entities, such as people, resources, applications, and the like, which make up the organization. For example, organizational information descriptive of an employee may include his/her name, job title, salary, telephone number, and/or internet protocol (IP) address. Organizational information describing an application may include the application's name and associated services provided by the application. Organizational information describing a resource may describe the resource as a network device (e.g., a printer), the name of the device, and capabilities provided by the network device. Many other types of organizational information may be maintained.
The organizational information is typically maintained in a number of data storage repositories. For example, the human resources (HR) department may have a data repository including information about each of the employees in the company. The information technology (IT) department may have a data repository of all passwords and internet protocol (IP) addresses associated with employees, applications, resources, etc. In a typical organization, each of the data repositories is independently maintained by the department that owns the repository. For example, the HR department maintains its own employee information, while the IT department maintains its own network information. However, data stored in these repositories frequently overlap, meaning that some information may be common among more than one repository.
Because each of the various data repositories is independently maintained by the department that owns the data repository, and there may be data common among them, inconsistencies may arise among the data repositories. For example, the HR department repository may have employee “John Smith,” and may list an email address of “johns@company.com;” the IT department may initially have John Smith's email address as “johns@company.com,” but may change the address to “johnsm@company.com” when another employee, “John Simpson,” joins the company. Thus, when the IT department changes John Smith's email address in the IT repository, the email address is no longer consistent with John Smith's email address in the HR department repository. For many other reasons, information stored in data repositories may become inconsistent within an organization. Thus, organizations typically attempt to manage their various data repositories so as to keep the information in them consistent, as well as up-to-date, accurate, and readily available.
In theory, in order to efficiently and effectively manage organizational data, the various data repositories could be replaced with one large repository, modifiable by the various organizational departments; however, this solution is impractical for a few reasons. First, in practice, political boundaries associated with departments in a typical organization make this solution impractical because departments typically want to control their own data. Second, departments are typically modeled on a division of labor model, wherein each department has expertise only with regard to the information with which the department is concerned. Thus, it is impractical to have, for example, the HR department updating IP address and email address information in one large repository.
As a result, traditional systems for managing an organization's data repositories and their associated organizational information involve linking the multiple repositories, while allowing the departments to independently modify their own repositories. In a traditional system, data from each of a number of repositories (remote repositories) is read by an associated interface that negotiates between the repository and a central repository that represents a combination of data in all the repositories. Each of the interfaces moves data from its associated remote repositories into the central repository.
As will be appreciated, in order to maintain a consistent and well ordered representation of the combined data in the central repository, some form of control must be establish over which data from which remote repositories is to be written to the central repository. In this regard, traditional systems often use the “authoritative source model,” in deciding which data is written to the central repository. In accordance with the authoritative source model, one remote repository is designated as the authoritative source for each given unit of data in the central repository. That is, one remote repository, or its associated interface, is given permission to modify the given unit of data in the central repository. For example, in an organization having an IT department repository and an HR department repository, the IT department repository may be designated as the authoritative source for employee telephone information in employee records in a central repository, while an HR department repository may be designated as the authoritative source for employee passwords in the employee records in the central repository.
In a typical system using the authoritative source model, the manner in which an authoritative source is actualized in the system is by coding the designated authoritative source into one or more processes in the system, using scripts and the like. Unfortunately, this makes changing the authoritative source difficult and/or time consuming. Furthermore, since the authoritative source model only allows for one authoritative source to be assigned to a given unit of data, that unit of data may remain out of date for some time if the designated authoritative source is off-line or otherwise inaccessible by the system.